home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19950528-19950726 / 000258_news@columbia.edu_Fri Jun 30 11:18:56 1995.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA13355
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Sun, 2 Jul 1995 06:01:25 -0400
  3. Received: by apakabar.cc.columbia.edu id AA27239
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Sun, 2 Jul 1995 06:01:23 -0400
  5. Path: news.columbia.edu!sol.ctr.columbia.edu!hamblin.math.byu.edu!park.uvsc.edu!news.provo.novell.com!news.cs.utah.edu!cc.usu.edu!jrd
  6. From: jrd@cc.usu.edu (Joe Doupnik)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: Configurable APC checking in next MSK release?
  9. Message-Id: <1995Jun30.171856.55074@cc.usu.edu>
  10. Date: 30 Jun 95 17:18:56 MDT
  11. References: <jhurwitDAuowt.ICo@netcom.com> <1995Jun29.071144.54932@cc.usu.edu> <jhurwitDAy11x.7Jq@netcom.com>
  12. Organization: Utah State University
  13. Lines: 63
  14. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  15.  
  16. In article <jhurwitDAy11x.7Jq@netcom.com>, jhurwit@netcom.com (Jeffrey Hurwit) writes:
  17. >     Thanks to both Frank and Joe for your comments.
  18. > 
  19. > In article <1995Jun29.071144.54932@cc.usu.edu>,
  20. > Joe Doupnik (jrd@cc.usu.edu) wrote:
  21. > 
  22. >>    The reason OUTPUT is on the dangerous list is this. Something
  23. >>on the host sends APC OUTPUT \26DEL *.* ST to your desktop machine. That's
  24. >>includes a form of nasty mail trouble (^Z to suspend currrent process,
  25. >             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  26. >>start removing files).
  27. > 
  28. >     Hmmm, I see your point.  I can see some visciousness on the part of
  29. >     someone (similar to ANSI bombs, right?  Someone would have to know
  30. >     that I'm using Kermit), but I'm not familiar with the kinds of
  31. >     system vagarities that would accidently trigger an unwanted APC
  32. >     command that would in turn cause damage on the host account.  I'll
  33. >     take your word for it!
  34. > 
  35. >>    I'm not sure we want to itemize commands which are dangerous
  36. >>because it is a bulky operation in the program and it adds to the doc
  37. >>complexity (must now explain how each candidate can be abused remotely
  38. >>etc).
  39. > 
  40. >     I didn't know it would bloat the program that much.  Having only
  41. >     recently stepped up from an 8088 portable with no hard drive, I
  42. >     really appreciate your continuing to support antiquated equipment
  43. >     with minimal resources!
  44. > 
  45. >     Ok, then let me try this suggestion:  Currently, MSK will ignore a
  46. >     'set apc unchecked' command in a script or macro if it was invoked
  47. >     with an APC command.  How about reversing this so that MSK will
  48. >     recognize and act on that command?  What I envision is placing a
  49. >     'set apc unchecked' just before a dangerous command, and 'set apc
  50. >     on' just after.  This way, the window of opportunity for a system
  51. >     burp setting off an unwanted command would be small, and an "APC
  52. >     bomb" in an e-mail message could do nothing at all without knowing
  53. >     the name of the script or macro.
  54. > 
  55. >     In fact, better yet, how about an "unchecked' command, to be used
  56. >     only in scripts or macros?  Placed just before the dangerous
  57. >     command (eg. 'uncheked output xxxx'), it could disable APC checking
  58. >     just for the duration of that command, and reestablish it
  59. >     immediately afterward.
  60. > 
  61. >     For the docs, you could simply list out the commands which are
  62. >     checked, following a brief and general discussion of the reasons
  63. >     for checking them.  More than that would not be necessary if the
  64. >     user has the option of an 'unchecked' command.
  65. > 
  66. >     How does this sound?  Would it add too much to the size and
  67. >     complexity of MSK?  I think it could provide a good balance between
  68. >     safety and flexibility if properly used.
  69. > 
  70. >                                         Jeff
  71. ---------
  72.     Well, er, a little confusing today, but I think I have your point.
  73. That point is let the APC command text contain a SET APC UNCHECKED string.
  74. Is that right? If so then there is no point to having checking at all;
  75. someone can do whatever they wish to your machine just by sticking such
  76. APC command material (with the APC  ST control codes too) in anything
  77. you display via Connect mode. Mail will do nicely.
  78.     Joe D.